!pr0
!lm12
!rm75
Explanation of the new DOS Append Bug..............Tom Weishaar
                                          Overland Park, Kansas

[ Tom is author of ProntoDOS, published by Beagle Bros, an excellent speed-enhanced DOS which happens to be compatible with nearly everything.  He also writes the monthly DOStalk column in Softalk Magazine. ]

I was behind on my reading when I wrote, in the April Softalk DOStalk, about the changes Apple made to DOS 3.3 in the new //e release.  At that time I noticed the routine used to calculate random access file position at $B331 had been modified, but the change looked insignificant to me.

It turns out this change was supposed to fix another bug in the Append command!  The change was very well documented by Art Schumer in the August 1982 Call APPLE, page 57.

In pre-//e DOS, Append called on this random-access file position calculator to reset the position-in-file pointer.  As you know, Append simply looks through a file byte-by-byte until it finds the end, which can be indicated either by a zero byte or by a lack of additional sectors.

When Append finds a zero byte in the file, it knows it has reached the end, but by then the position-in-file pointer is one byte beyond the zero and has to be backed up.  Somebody once thought a call to the random-access file position calculator would be a good way to do this.

But on sequential files (the only kind you can append to) the File Manager uses a record length of one.  Thus files longer than 32767 bytes come to this routine with more than 32767 "records", which is beyond what DOS normally allows.  The calculation fails.

Schumer's patch gets it to calculate correctly right up to 65535.  At that point it stops working for good.  Apple tried to get around this in //e-DOS by throwing out Append's reliance on the random-access calculator.  Instead they go back in and change the position-in-file pointer directly, then trick the File Manager into re-saving his workarea.

Problem:  they only decrement the low byte of the position-in- file pointer.  If the file-ending zero comes in the last byte of a sector, the high byte will have been advanced to point at the next sector.  Since they don't decrement it, the position- in-file pointer is 256 bytes beyond where it should be.
Uh Oh...!

I've been trying to get folks at Apple to recognize the problem, but Append doesn't appear to be one of their priorities.  If they don't do something soon I'll publish a patch in Softalk.  I'd do it now, but I fear treading where so many have failed before me.
